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7.0 OBJECT CODE E NVIR ON MENT AND FORMATS 



7.1 INTRODUCTION 



Object information for any module in IPLOS may reside in two 
different formats! object modules and load modules. Object 
modules are the output of comDilers and the input to both the 
loader and OBLIGE* the library generator. Load modules are only 
output by OBLIGE and may be input to the loader and OBLIGE as 
well. Two formats are provided for approximately the same 
purpose to allow one of the formats (object module) to be 
amenable to compiler code generation? and the other to be 
amenable to operating system purposes (i.e. sharing of code). 

Table 7-1 summarizes the differences between ob| ect modules 
and load modules. 
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I OBJECT MODULE 



1 LOAD MODULE 



I structure I binary file of record I a virtual memory segment 
I I descriptor-record pairs? I 

I I each pair representing I 

I la logically discrete I 

I I entity J 



I access I SWL standard I/O 
+ + 

I output I compilers 

I from I 



I directly addressed 



I library qenerator 
I (OBLIGE) 



I inout to I loader 
I I OBLIGE 



I I oader 
I OBLIGE 



• code I no : code section is in I yes J code is in exec- 

I shared? I record format which I utable form; same phys- 

* I must be copied for each I ical image can be given 

i I instance of execution I to each instance of exec- 

II I ution 



I residency I binary files only 
+ — ♦ -. 



I IPL library segments onl yl 
-+ — *. 



TABLE 7-1 
Object module- load module summary 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.2 OBJECT MODULE SUMMARY 



Any program executing under IPLOS may have three ma) or kinds 
of components which reside in different segments having different 
characteristics and protect ion - attributes. The IPLOS object and 
load module structures are designed to support that three part 
environment. The three Kinds of components are code, working 
storage and binding. Table 7-2 summarizes the protection, 
contents and characteristics of the three sections. 



I PROTECT I CONTENTS 



CODE 



-I- 

I read 



I CHARACTERISTICS 
.j 



-I- 

i. reentrant l.sharable among all activa- 



I execute I instructions! tions; if module is in load 
I I. constant I module format, every activa- 

I | data I tion shares the same physical 

I I I coDy 

j I I .only one per module 



WORKING I section I .all unshared I . nonshared among all activa- 



STORAGE I depend- I or modifi- 



5 ent 

I 
I 
I 



I able data 

I 
I 
I 
I 
I 



I tions? a new copy is provided 

I for each instance of exec- 

I ution 

(•typically multiple sections 

I per modul e 

I .protection attributes are 

I compiler specified 



— + * * 

BINDING I 
I 



+ + + - 



read I .pointers or I .nonshared among all activa- 
binding I pointer I tions; a new copy is orovided 
I pairs I for each instance of exec- 
} . word aligned I ution 

I I .unstructured? no ordering 

I I relationship may exist be- 

I 1 tween pointers or pointer 

I I pairs 

I I. binding attribute is admin- 
I I istered by IPLOS ; may not be 
I I compiler specified 
1 I .only one per module 
+ * ------ -+ 



TABLE 7-2 
Program components 

A more detailed description of the object and load modules 
and the object environment is provided in the ensuing sections. 
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7.2 OBJEQT M ODUL E SUMMARY 



The object module 
following topology? 



is a file of binary records with the 



<record descriptor 1> 

<record 1> 
<record descriptor 2> 

<record 2> 

<record descriptor n> 
< re cord n> 

Each record descriptor contains two fields which define the 
ensuing records 1. )record type and 2.) length (record type 
dependent). The length field is used chiefly to fix the lengths 
of adaptable arrays. 

For the sake of simplicity, the record descriptoi — record 
pairs will be referred to as records in the remainder of this 
document. 



The following is a list 
record of the ob j ect. modul e t 



and explanation of each variant 



Record 
U2 

IDR 

SDC 



£X£i3Dali.on. 



of 



the modul e? 



Identification record? first record 

specifies module name and attributes. 

Section definition record? specifies length and 

attributes of every object module section (code, working 

storage, and binding) and all common blocks. 
TEX Text record? specifies data to be placed into any 

section. 
RPL Replication record? specifies data to be repetitively 

inserted into any section. 
BIT Bit insertion? inserts a specified subset of a byte Into 

any section. 
EPT Entry point definition? defines an address in any section 

as a named external I y accessible value. 
RIF Relocation information? defines those areas in each 

section. which must be modified by OBLIGE when binding 

modules together? not processed by the loader. 
AIN Address insertion? replaces or adds the address of a 

section of the module to another location within a 

module? allows the construction of full PVAs at load 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.3 LOAD MODULE - LIBRARY SEGMENT SUMMARY 



time? required since the ring number* segment number, and 

offset of each section are only determined at load time. 
AOI Address offset insertion? essentially the same as AIN 

above except that a (secti on, of f set) may be replaced or 

added. 
XRL External reference linkage? specifies a list of addresses 

in the containing module into which the address of the 

named external is to be placed. 
TRA Transfer record? specifies a.)the primary entry point and 

b.) the end of the object module. 

object module records must be arranged in the following 



The 
order: 



i.)IDR record 

2.)SDC records for all object module sections 

3.)TFX,RPL,BIT, EPT, RIF, A IN, A 01, and XRL records 

order 
4.) TRA record 



in arbitrary 



The records in group three are not required t o be in any 
order, however they will be processed by the loader in the order 
that they are received. Therefore some concern must be given to 
the order in which they are generated. 
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7.3.1 LIBRARY SUMMARY 



A library is a directly addressible virtual memory structure 
which contains a number of modules plus the module and entry 
point dictionaries required to retrieve them. 
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The components which organize and define the load modules on 
a library are as follows: 



CO MPONENT 
Library header 
Subprogram dictionary 

Procedure dictionary 



Entry point : module 
dictionary 



Identifies the library? con 
pointers to the library die 
Contains the name, at 
relative pointer to the loa 
each subprogram module, 
to subprograms. 
Contains the name, at 
relative pointer to the I 
each procedure module? us 
during library generation. 
Contains the relative point 
module for each entry po 
procedure module? used by 
load modules associated wit 
entry point. 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.3.2.1 Module header 



7.3.2 LOAD MODULE SUMMARY 



A detailed format of the load module is not available at 
this time, however an outline of the major elements of the load 
module and of the components of each element is Drovided below. 

The load module consists of six major elements* the module 
header* the code element, the linkage element, the working 
storage element, the entry point definitions, and the information 
element. The components of each element are summarized below. 



7.3.2.1 Module header 



modu 
diet 
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Comm 



load module header identifies and organizes the load 
The header is pointed to by one of the module 

ies of the library in which it resides. It contains the 
items? 

e header header 

ary entry point name 

oointer to procedure or subprogram module dictionary 

y for this module 

le generator code 

le generator name and version 

/date created 

ter (relative to module header header) of section 

nition I ist 

er of section definitions 

ter (relative to module header header) of load module 

er of load module mao entries 

entary supplied at module generation time 

def ined 



Section definition list entry - one for each section 
in the load modul e 

- Sect ion type 

- Section attributes 

- Sect ion I ength 

- Maximum length for extensible sections 

- Section alignment 

- Name for common blocks 

Load module map entry - one for each element of the load 
modul e 

- Element type 

- Pointer (relative to the library segment) of the element 

NCR/CDC PRIVATE REV 28 JAN 75 
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Element length 



7.3.2.2 Code ele ment 



The code element may contain constants, instructions and 
relative pointers to other sections. This element must be 
nonsel f modi tying to enable the element to be shared by all 
activations of the load module. 



7.3.2.3 Linkagg element 



The linkage element contains the names and linkage chains 
for all external references made by this load module. 



7 • 3 • 2 • *» Wo rking stora ge 'ele ment 



The working storage element contains the interpretive 
initialization information for all the working storage sections 
and common blocks defined in the module. Each of these sections 
is allocated and initialized for every activation of the module. 
Since the code section is not modified at load time, all 
modifiable data and full address pointers must reside in working 
storage sections. 



supported 



The kinds of interpretive initialization records 
in the working storage element are as follows: 

Record Record 
ID. Najne 

TEX Text insertion record 

RPL Replication record 

BIT Bit insertion record 

A IN Address insertion record 

AOI Address offset insertion record 



Since the System/hardware calling convention only provides a 
called module with the address of its binding section, the 
binding section must contain sel f -ref erenc ing links which allow 
the code section to find the appropriate working storage sections 

NCR/CDC PRIVATE REV 28 JAN 75 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.3.2.6.3 RELOCATION INFORMATION 



at execution time. 



7.3.2.5 5 i ntry. i ppint i definitions 



The entry point definitions are a list of all the named* 
externally accessible addresses in the load module. 



7. 3.2. 6 Information element 



The information element contains information which does not 
belong in the other four elements* notably relocation information 
for library generation, module information* compiler generated 
symbol tables* etc. The el ement- consists of a header and several 
tables which rrake up the body of the information element. 

7.3.2.6.1 INFORMATION ELEMENT HEADER 

The information element header organizes the information 
element. It contains the list headers for the other components 
of the information element. 

7.3.2.6.2 pOMPON E NT I DE NTIFICATION 

A load module may consist of several object and load modules 
bound together by OBLIGE. In this C3se a component 
identification entry is maintained for each of the original 
components of the module. Each entry consists of the following 
items? 

Module name 

Module generator code 

Module generator name and version 

Time/date created 

User supplied commentary 

7. 3. 2. 6. 3 R ELOCATION IN FORMATI ON 

Relocation information is used by OBLIGE when binding object 
or load modules together. It identifies every offset relative to 
the base of either the code or binding section which must be 
altered to reflect the offset in the new bound module. 
Relocation information is not used by the loader when the module 
is loaded. 
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Each relocation information item consists of the following! 

• Section and offset containing field to be relocated 

. Section to which field is to be relocated (i.e. code or 

binding) 
. Size and kind of field 

• Sign and type of offset contained within the field 

7.3.2.6.4 BINDING SFCTION TEMPLATE 

The binding section template is produced by OBLIGE whenever 
it creates a load module. It identifies the contents of each 
word in the binding section for the load module. 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.4.1.2 Working storage sections 
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7.<* OBJECT ENVIRONMENT AND CONVENTIONS 



7.<+.i OBJECT COMPONENTS 



Any program executing in IPLOS has an 
consisting of three types of components* cod 
storage sections* and binding sections. A sin 
or load) consists of a single code sectio 
section* and multiple working storage sections 
is separated from the working storage section 
the sharing of the code section among multiple 
module. The binding section is separated 
storage sections in order to a.)allow control 
rings of protection and b_«) allow the binding 
load modules to be combined during library 
elimination of matching entry point-external 
external references. 



7 . *t . 1 • 1 Code sections 



All code produced by standard IPL compiler products must be 
reentrant to allow it to be shared among all activations of the 
module. The code section of every module* therefore* should only 
contain nonsel fmodi f ying instructions* constant data and relative 
pointers to other sections. There may be no more than one code 
section per module. 

Since the object module may contain code that has been 
generated discont iguous ly (i.e. not in the order in which it is 
to be executed), the code sections of object modules are 
allocated in a segment INITIATEd at load time for every 
activation of the module. However, should that module be 
processed by the library generator and reformatted into a load 
module, its code section will be in executable image and will be 
shared among all activations of the module. 



7 • t* . i . 2 Working storage 



Working storage sections contain all modifiable* nonshared 
data used during a modules execution. There may be an arbitrary 
number of working storage sections oer module each having its own 
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attributes specified by the program that generated the module. 

The attributes that may be specified for each working 
storage section are as follows! 



S£CHOJvLlYPf 

Working storage 



Common block 



Extensible working 
storage 

Extensible common 



PROTECTION ATTRIBUTES 

Read 
. Write 

• Execute 

• Binding 



ALLOCATION ATTRI BUTE S 

• Length 

• Maximum length 

• Al ignment 



Fixed length known at allocation time and 
unchanging during execution; always 
allocated and initialized when module is 
I oaded • 

Named data section equivalent to FORTRAN 
common, SWL external* PL/1 static 
external, and COBOL (ATG) global? 
allocated once for every task. 
Like working storage except length may 
increase during execution* maximum length 
is specifiable. 

like common block except length may 
increase during execution* maximum length 
is specif iab le. 



Indicates section 
Indicates section 
Indicates section 
Indicates section 
this attribute is 
system and may 



specified in 
7.^.1.3). 



is readable 
is wr itab le 
is executabl e 

is a binding section; 

administered by the 
therefore only be 



the binding section (c.f. 



Section length; initial allocation for 
extensible sections. 

Maximum length for extensible sections. 
Byte alignment of section; section is 
allocated starting at a MOD alignment 
byte address. 



7.^.1.3 B inding s ection s 



The binding section may be thought of as a special class of 
working storage section that is administered by the Operating 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.*f.i.3 Binding sections 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.^.1.3 Binding sections 



System. There may be only one binding section oer module just as 
there may be only one code section. Binding sections are 
allocated in a segment that has the read and binding protection 
attributes and does not have the write attribute in user rings. 
Furthermore only the Operating System may INITIATE a segment with 
a binding attribute? users may not. 

In order to insure the efficacy of the binding section, 
several conventions concerning it must be adhered to by all 
modules executed in . IPLOS. These conventions have been 
established to achieve the following ends! 

1.) Assure the integrity of crossing ring of protection 
boundaries? one of the requirements of protecting one piece 
of code from another is that the protected code only be 
entered from points at which it is prepared to receive, 
control. Branching to arbitrary entry points within a piece 
of code could cause undefined* possibly destructive results. 

2.)AMow the binding sections of several modules to be combined 
at library generation time in such a fashion that: 
a.) Further processing of matching entry-external references 

at I oad time is eliminated in some cases. 
b.)Redundant external references are removed thereby reducing 
the overall size of the combined binding section of the 
new module. 

3.)Provide a consistant mechanism for all pure procedure code 
(user and system) to discover the data base associated with 
the appropriate instance of execution. 

The conventions associated with the binding section are as 
f ol lows! 

l.)0nly the Operating System may INITIATE a segment with the 

binding protection attribute. 
2.)The binding section is readable but n.ot writable in the users 

ring of protection. 
3.)The only data that may be stored in the binding section are 
pointers* and they must be in one of the three following 
.forms J 

a.)Forty eight bit data pointer* right Justified in a full 
word with the two unused bytes zero filled? aligned in a 
full word. 
b.)A sixty four bit internal procedure code base pointer? 

aligned in a full word 
c. ) A 128 bit external procedure code base-binding section 

pointer pair? aligned in two full words. 
Despite the fact that the binding section is readable in the 

NCR/CDC PRIVATE REV 28 JAN 75 
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user ^ing» placement of constant data is 

explicitly .distil owed to prevent generation of erroneous 
entry points to more privileged rings under false pretenses. 

*f.)The only data that must be stored in the binding section 
(i .e. hardware requirement) are internal and external 
procedure descriptors (i.e. 3b and c above). 

5.)The binding section must be unstructured? that is no 
predetermined order can be assumed between binding section 
entries since a given entry's relative location within the 
binding section may change independently of any other entry 
during library generation. This implies that address 

arithmetic (indexing) or assumptions about pointer contiguity 
are not permitted with regard to the binding section. 

6.)The Operating System/hardware calling convention only 
provides a procedure with the address of its binding 
section. This implies that the base address of at least one 
of the module's working storage sections must be stored in 
the binding section. 
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7.0 OBJECT CODE ENVIRONMENT AND FORMATS 
7.6 MODULE CONVENTIONS 



7.5 SE £11 ON_z_SE£M£NI_ALLOC A II ON 



Table 7-3 summarizes the segment allocation that taKes place 
for each type of module section when a program is established as 
a task. 



ISECTION! 



SEGMENT ALLOCATION 



CODE I. one segment per ring for the code sections of all the I 

I object modules in the object file list I 

I. one segment per system for each library in the library I 

J segment I ist I 



WORKING I .one segment per ring per access attribute set in which I 

STORAGEI all non-extensible working storage sections and common t 

I blocks are allocated 1 

I • one segment for each extensible working storage sectionl 

I and common block I 



+ + 

J BINDINGl . one segment 


+ 

for all binding sections of all the modulesl 


1 1 in a task 
+ + 


I 

• 4. 



TABLE 7-3 
Module-segment allocation 
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7.6 MQD.ULE CONV ENTIONS 
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7.7 DETAILED MODULE FOR MATS 1 

2 

3 

A detailed listing of the current version of the type 4 

definitions of the object module is available in catalog GSB in 5 

an ASCII list on file OBJTEXT and in the outDUt listing of ISWL 6 

on the fi le OBJSWL. 7 

8 

A detailed listinq of the load module is not currently 9 

avai table* 10 
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